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CATALOG MANAGEMENT SYSTEM 
ARCHITECTURE HAVING DATA TABLE 
OBJECTS AND LOGIC TABLE OBJECTS 

TECHNICAL FIELD 

The invention relates generally to object-oriented data 
processing and system management, and more particularly 
to a layer of abstraction providing location and type inde- 
pendence in accessing configuration information in a catalog 
environment. 

BACKGROUND OF THE INVENTION 

Many executable software programs or applications 
require access to system-wide, configuration-type informa- 
tion at times when the application is being installed or 
modified on a computer system, i.e., at configuration time 
and at the time the application is executed to perform its 
intended function, Le., at run time. The application needs to 
access configuration information related to available 
resources on the local computer system and through con- 
nected computers across a computer network. These 
resources include available software and hardware tools as 
well as available services offered by the system that improve 
the functionality of the program within the overall system. 

Accessing this information is typically done through 
direct access to a "registry" located on each computer 
system. The registry is simply a place to store and read 
configuration information. Meanwhile, a transaction man- 
agement system provides services through embedded logic 
to an application. The services may relate to such items as 
security, validation, roles, etc. as well as network commu- 
nication and conflict management 

The services are typically exploited through an attribute- 
based programming scheme which allows program devel- 
opers to specify the services and resources required by an 
application by setting properties (or "attributes") of each 
application or component rather than implementing or call- 
ing those services directly from the implementation code. 
Attributes include a particular set of configuration informa- 
tion that is made available to various callers in an attribute - 
based environment. 

Even in an attribute-based programming environment, the 
application desiring data and services must know where the 
information comes from in the system. Moreover, the pro- 
gram typically must know the format that the information is 
stored in to be able to access the information. In existing 
approaches, the system registry has been used to store 
configuration data for a particular machine. However, in 
existing approaches, a programmer was required to access 
and manipulate registry information directly, introducing 
undesirable program complexity and exposing the registry to 
corruption by improper programming. Moreover, the distri- 
bution of configuration information among multiple datas- 
tores (i.e., in addition to the registry) and data formats is not 
accommodated by existing approaches, particularly if the 
location and format of data is expected to evolve over time. 
In current approaches, the implementation code itself must 
be altered in order to handle location and format changes to 
configuration information. Accordingly, existing approaches 
lack location and format independence that can provide the 
desired flexibility for storage and access to configuration 
information in a computer system. 

It is with respect to these and other aspects that the present 
invention has been made. 

SUMMARY OF IKE INVENTION 

The present invention relates to an abstraction layer in a 
catalog management system for accessing system configu- 
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ration information. The catalog management system pre- 
sents the configuration information that is stored in a datas- 
tore to a computer process caller. In order to present the 
information to the caller, the catalog management system 

5 retrieves the information and then stores it in cache memory 
so that the datas to re is encapsulated from the caller. The 
request for the configuration information may be both loca- 
tion independent and type independent. 
In accordance with preferred aspects, the present inven- 

10 tion relates to an abstraction layer having a data table object 
interface module and a logic table object module. The data 
table object module has a cache memory module which is 
accessible by the caller and is adapted to store the configu- 
ration information to be presented to the caller. The data 

15 table object module also has a datastore interaction code 
module which is adapted to retrieve the configuration infor- 
mation from the datastore and populate the memory with the 
information. The logic table object has an interception/ 
delegation module which intercepts calls from the caller and 

20 delegates commands to the data table object interface mod- 
ule to provide an additional layer of processing. The abstrac- 
tion layer preferably uses a wiring database to determine the 
location of the datastores to provide the configuration infor- 
mation. 

25 These and various other features as well as advantages 
which characterize the present invention will be apparent 
from a reading of the following detailed description and a 
review of the associated drawings. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a pictorial representation of a suitable 
client-server computing environment in which an embodi- 
ment of the present invention may be implemented in both 
35 clients and servers. 

FIG. 2 depicts an exemplary client/server architecture 
employing both runtime and configuration time catalog 
systems in accordance with the present invention. 
FIG. 3 illustrates an exemplary system for implementing 
40 the invention in an embodiment of the present invention. 
FIG. 4 depicts various examples of logic table and data 
table combinations in embodiments of the present invention. 
FIG. 5 depicts a table dispenser system for dispensing 
45 logic and data table objects such as those depicted in FIGS. 
2 and 4. 

FIG. 6 shows a data table object, such as one of the data 
tables shown in FIGS. 2 and 4. 

FIG. 7 shows a logic table abstraction layer used in 
50 combination with data table objects. 

FIG. 8 illustrates a logic table abstraction layer imple- 
menting embedded logic used in combination with data table 
objects. 

S5 FIG. 9 represents a flow chart of logical operations 
creating an abstraction layer of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

60 An embodiment of the present invention relates to a 
catalog management system that uses logic table objects and 
data table objects, which are distinct units of program code 
known as "objects" to present configuration information 
from one or more datastores in a computer system to a 

65 requesting or calling program, i.e., a caller. The logic and 
data table objects provide a layer of abstraction between the 
caller and the datastores alleviating the caller from needing 
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to know the actual location of the datastorc housing the machine. Therefore, the term "caller" is used hereinafter to 
configuration information or the format in which the infor- indicate a client-type process that requests information or 
mation in the datastore is stored. Moreover, the layer of services from another operation or process, 
abstraction provides access to configuration information As part of the sophisticated network adrninistration, each 
from one or more datastores at the same time. The caller 5 computer must be able to access applications and resources 
merely provides a request for the information, using a available on the other computers in the network 100 and 
relatively high level description of the information and the therefore must be able to access configuration data related to 
catalog management system of the present invention deter- the applications and resources available on the other corn- 
mines the location of the requested information and presents puters. The configuration data is located within memory on 
the information to the caller in a meaningful format. The 10 each computer system, i.e., in a datastore. Additionally, each 
catalog maintains a 'Sviring database" that is recursively computer system typically has more than one datastore of 
called to construct the proper logic and data table objects of configuration information that needs to be accessed by the 
the abstraction layer which ultimately presents the configu- other computer systems. Moreover, the different datastores 
ration information to the caller. may each have different data types or formats. In order to 

A computing environment 100 in which an embodiment 15 access configuration information from these many and vari- 

of the present invention may be implemented is shown in ous computer datastores, a client or caller, i.e., the system or 

FIG. 1. Client computer systems 102, 104, 106 and 108 are process making the request for information, communicates 

connected to server computer systems 110, 112, 114 and 116 with a "catalog" interface on the server computer system, 

by a network connection 118. Additionally, client computer piG. 2 depicts an exemplary client/server architecture 

120 is connected to server computer 110 via a communica- 20 employing COM+ catalogs in accordance with the present 

tions link, such as the Internet 122. Since the server 110 is invention (COM is an acronym for Component Object 

connected via the network connection 118 to the other Model). A COM+ Catalog is a virtualized database of 

servers 112, 114 and 116, the client computer 120 is also COM+ applications and their services, with runtime and 

connected and may access information on the other servers configuration-time abstraction layers for using and manipu- 

112, 114 and 116. 25 lating configuration information. An embodiment of the 

The client computer systems 102, 104, 106, 108 and 120 present invention, for example, may be employed in a 
operate using at least some of the information and processes component-based programming model of a transaction pro- 
available on at Least one of the servers 110, 112, 114 and 116. cessing runtime environment for developing, deploying, and 
Additionally, the clients 102, 104, 106, 108 and 120 can each managing high-performance, scaleable, and robust enter- 
access the various shared resources provided by any other 30 prise Internet and intranet server applications, 
computer on the network 100. Each client is a complete, a "component" is software containing classes that may be 
stand-alone personal computer and offers the user a full created and exposed as "objects" (i.e., self-contained pro- 
range of power and features for running applications. The grammed entities that consist of both data and functions to 
clients 102, 104, 106 and 108, however, may have different ^ manipulate the data) for use by another application. A 
operational features as compared to the other clients, but component can also use objects exposed by another appli- 
each client is able to communicate with the servers and other cation. For example, a developer can create an application 
clients via the common interface 118. using ActiveX components that can be updated and managed 

The servers 110, 112, 114 and 116 are either personal easily as in-process DLLs (Dynamic Link Libraries). The 

computers, minicomputers, or a mainframes that provide ^ DLLs are then installed into the COM environment for 

traditional strengths offered by minicomputers and main- execution within the application. Components can be devel- 

frames in a time -sharing environment: data management, oped specifically for a developer's single application, devel- 

information sharing between clients, and sophisticated net- oped for use with multiple applications, or purchased from 

work administration and security features. The client and a third party. 

server machines work together to accomplish the processing 45 COM technology allows a piece of software to offer 

of the application being used. Working together in this services to another piece of software by making those 

manner increases the processing power and efficiency services available as "COM objects." COM is a foundation 

related to each independent computer system shown in FIG. for an object-based system that focuses on reuse of inter- 

1- faces. It is also an interface specification from which any 

Typically, the client portion of an application executed in 50 number of interfaces can be built. Each COM object is an 

the distributed network 100 is optimized for user interaction instance of a particular class and supports a number of 

whereas the server portion provides the centralized, multi- interfaces, generally two or more. Each interface includes 

user functionality. However, each client computer 102, 104, one or more methods, which are functions that can be called 

106, 108 and 120 can perform functions for other computers, by the objects' clients. 

including the clients and servers, thus acting as a "server" 55 COM+ technology is an extension of COM technology 

for that other computer system. Similarly, each of the servers that includes a new runtime library that provides a wide 

110, 112, 114 and 116 can perform functions and relay range of new services, such as dynamic load balancing, 

information to the other servers, such that each server may queued components, an in-memory database, and events, 

actually be a "client" requesting information or services COM+ technology maintains the basics of COM technology, 

from another computer in particular circumstances, qq and existing COM-based applications can continue to work 

Therefore, the term "client," as used hereinafter refers to any unchanged in a COM+ environment, 

computer system making a call or request of another com- An object implemented to comply with COM+ is referred 

puter system and the term "server" is the computer system to as a "COM+ object". A component that includes one or 

that services the request. more classes that may be instantiated as a COM+ object is 

On the other hand "client processes," which refer to 65 referred to as a "COM+ component". Each COM+ compo- 

operations that request information or services from "server nent has attributes, which can be set in a component (or type) 

processes" may actually be communicating on the same library. Attributes are a form of configuration data required 
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by many software components to execute correctly and libraries, SQL (structured query language) Servers, and the 
completely. An application that includes COM+ components NT Directory Service (NT DS), whereas examples of data- 
is referred to as a "COM+ application". When a component bases include: server group databases, download databases, 
is made part of a COM+ application, its component (or type) and deployment databases. 

library is written into a COM+ catalog. When an object is 5 A daU UWe ob] ^ ^ ^ data ^ object ^ ^ a 

instantiated from that component, the attributes in the A . . M . #„ki- ~u:~~ t *u«* „ »„ui<» „,„ nr 

A . • j~* * j * jl l* * . datastore-dependent table object that exposes a table cursor 

COM+ catalog are examined to determine the object context . . r . . . . J ~ * ui -j 

4 , . & f *u u- * t> j #u r- , into a particular datastore. The table cursor provides a 

that contains properties for the object Based on the object M . * , 4 L1 . . . . t , . . , t r 4 . 

context, othcSces required by the object are provided. Zf'^ tab ! e -° ne ° te f d * e datastore w ^e 

la this manner, a developer can merely identify in the ,„ hidmg the loc^Uon and fonnat of the underlymg datastore 

attributes the additional functionality required by the object, 10 • ^ example, a caller can use a table cursor to navigate 

and based on the object's attributes, the appropriate other ,he , ™ ° f » c * ta,nn m a ^ P resented t0 

services that are available within the system, or the acces- caller Dy a uwe 0D,ecL 

sible network, are executed to provide that functionality. ^ 12016 ob i ect K 0011,1(1 to a particular datastore 

In FIG. 2, a client computer 200 is coupled via a network „ accessible within the computer. For example, a data table 

to one or more remote computers (e.g., a computer 202 and d** 1 ma y bc bound to «•« "Ptfry m P™vide the registry 

a server 204). Although the embodiments of the present data 10 ^ form to a h ^ cr lcvcl < e S-> an ovcrlald lo 8 lc 

invention are illustrated and described herein relative to ^ oh i ect > server object, or runtime catalog), 

multiple computer systems coupled by a computer network data table ° b j ect mav te bound tomer ^T Directory 

or other communicauons connection, it is to be understood M Services to provide directory configuration data to a higher 

that an embodiment of the present invention may be level. As shown by data table objects 238 and 240, multiple 

employed in a stand-alone computer system to provide data table objects may be created for a single datastore (e.g., 

access to configuration information in the system. data 18016 00 i 6Cts 238 30(1 240 are created b y different logic 

A client application 206 executes on the client computer tablcs ob i ects to P rovidc acC6SS t0 same datastore 242). 

200 to access a server application 208 executing on the 2s ^ ^ table ob j ect 222 POP 11 * 3165 one or more internal 

server 204. For example, the server application 208 may caches with read or write data associated with the datastore 

include a database application that receives a query from the 214. Queries to the datastore 214 are serviced by the cache 

client application 206 and accesses a customer database (not or caches through the data table object's table interface, 

shown) for all customer data satisfying the query. During Usin g al least 0De "update" method, data in the read cache 

operation, the server application 208 may require configu- 30 °f data ta °l e °bj ecl 222 may be refreshed from the datastore 

ration data recorded in a datastore (such as datastores 214 or 214 »nd data in a write cache may be flushed to the datastore 

216). For example, a transaction server application can 214. Data table objects are described in more detail below 

determine the security level of a user according to a "role" and in U.S. patent application Ser. No. 09/360,442, entitled 

assigned to the user by an administrator or other means. "DATA TABLE OBJECT INTERFACE FOR 

Accordingly, the transaction server application might query 35 DATASTORE," assigned to the assignee of the present 

a role definitions database to validate the user's access to a application, filed concurrently herewith and incorporated 

transaction database (not shown). In another example, the herein bv reference for all that it discloses and teaches, 

server application 208 accesses configuration information to A logic table object, such as logic table object 220, 

verify that required services are available for its execution. presents domain-specific table data by logically merging or 

To obtain configuration information in the illustrated 40 consolidating table data from multiple data table and/or 
embodiment, the server application 208 accesses a runtime logic table objects, supplementing table functionality, and/or 
catalog 210 running on the server 204. The runtime catalog synthesizing data into the table, in accordance with a given 
210 causes one or more table object dispensers to create type of configuration information requested (e.g., configu- 
catalog table objects (shown generally as table system 218) ration information for Components, Applications, etc.). The 
providing the required configuration data in a table to the 45 domain-specific nature of the table data is preferably defined 
server application 208. A "table object" includes an object by at least one table dispenser input parameter, including 
that provides a caller with access to underlying data, pre- without limitation a database ID, a table ID, a query 
sen ting that data in virtual "table" format through a defined parameter, or a level of service parameter). Logic table 
table interface. A table object may also provide its own objects in a COM+ Catalog environment are type- 
functionality, read and write caching and the triggering of 50 independent abstraction layers between a caller (such as the 
external events, in addition to other features. The table data runtime catalog 210) and one or more datastores (such as 
is accessed by a caller (e.g., a catalog server, a runtime datastores 214 and 216) containing configuration informa- 
catalog, or an overlaying logic table object) by way of a tion. A logic table object typically sits atop one or more data 
table-oriented interface, preferably including table cursor table objects and introduces domain-specific rules and pro- 
methods. In the exemplary embodiment, the runtime catalog 55 cesses to the underlying data table objects, although other 
210 accesses configuration data in the datastores 214 and configurations of table systems are possible (see FIG. 4). 
216 through layers of abstraction provided by the table More specifically, a logic table object can logically merge 
system 218 (Lc., including logic table objects ("LT"), such or consolidate configuration data from multiple data table 
as logic table object 220, and data table objects ("DP% such and/or logic table objects into a single table based on 
as data table object 222). eo predetermined logic (e.g., according to type). Furthermore, 

A globally unique database identifier ("DID") identifies a logic table object can supplement data table object func- 

each catalog database. A given DID guarantees a minimum tionality by intercepting interface calls from a client and 

well-defined set of catalog tables, each table being identified adding to or overriding the underlying table object function - 

by and complying to the rules of a table identifier ("TID"). ality (e.g., adding validation or security). Additionally, a 

A DID is a datastore-independent identity, meaning that the 65 logic table object can synthesize data that is not available 

tables of that database can be distributed among multiple from the underlying datastores or tables and present the 

datastores. Examples of datastores include the registry, type synthesized data as part of the table. Logic table objects are 
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described in more detail below and in U.S. patent applica- With reference to FIG. 3, an exemplary computing system 

tion Ser. No. 09/360,440, entitled "A LOGIC TABLE for embodiments of the invention includes a general purpose 

ABSTRACTION LAYER FOR ACCESSING CONFIGU- computing device in the form of a conventional computer 

RATION INFORMATION/* assigned to the assignee of the system 300, including a processor unit 302, a system 

present application, filed concurrently herewith and in cor- 5 memory 304, and a system bus 306 that couples various 

porated herein by reference for all that it discloses and system components including the system memory 304 to the 

teaches. processor unit 300. The system bus 306 may be any of 

The foregoing discussion has described the COM+ Cata- several types of bus structures including a memory bus or 

log environment as used at runtime by an application. An memory controller, a peripheral bus and a local bus using 

alternate use of a COM+ Catalog occurs at configuration- 1Q any of a variety of bus architectures. The system memory 

time and may employ one or more catalog server objects includes read only memory (ROM) 308 and random access 

("CS") and one or more client table objects. During memory (RAM) 310. A basic input/output system 312 

configuration, an administration tool, such as Microsoft's (BIOS), which contains basic routines that help transfer 

Component Services administration tool or COMAdmin information between elements within the computer system 

Library, is used to create and configure COM+ applications, 300, is stored in ROM 308. 

^L*T rt C01 1 + Wlicatiaijs. manage 15 ^ c mmvntCT syslcm 300 further includes a hard disk 

installed COM+ applications and manage and configure drivc 3U fof readm from ^ to a hard ^ a 

services locally or remotely. Acconhngly, in addition to the fc ^ k ^ * M f ^ ^ 

illustrated embodiments, an embodiment of the present ^ , , r j-Viu Til-, j- «2 

invention may be employed by a local administration tool *™vable magnetic disk 316, and an optical disk drive 318 

managing an application running on a remote computer 20 for reatog from or wnbng to a removable ophcal disk 319 

system such as a CD ROM, DVD, or other optical media. The hard 

The exemplary administration tool 224 executes on the <|isk *™ 312 ' ^ ^ * 14 if£ ^ 

client computer 200 in FIG. 2. An alternative administration *ive 318 ™ co ™ ccted to lhc 306 by a hard chsk 

tool (such as administration tool 250) can execute on another dnve interface 320, a magnetic disk drive interf ace 322, and 

computer (such as server 204) to configure applications and 25 m pptical drive interface 324, respectively. The drives and 

services executing in the computer. A catalog server object, tnc i r associated computer-readable media provide nonvola- 

such as catalog server objects 226, 228, and 230, manages tile storage of computer readable instructions, data 

configuration information on its computer. All administra- structures, programs, and other data for the computer system 

tion requests to a computer, whether local or from another 300. 

computer, go to a catalog server object on that computer, 30 Although the exemplary environment described herein 
preferably through one or more abstraction layers, including employs a hard disk, a removable magnetic disk 316, and a 
client table objects and logic table objects. removable optical disk 319, other types of computer- 
A client table object ("CT") is analogous to a data table readable media capable of storing data can be used in the 
object that binds to a particular local or remote catalog exemplary system. Examples of these other types of 
server object instead of a datastore, presenting the configu- 35 computer-readable mediums that can be used in the exem- 
ption information marshaled by a catalog server object in plary operating environment include magnetic cassettes, 
table form to the caller, such as the administration tool 224. flash memory cards, digital video disks, Bernoulli 
The local catalog server object 226 manages configuration cartridges, random access memories (RAMs), and read only 
data locally on the client computer 200, while the remote memories (ROMs). 

catalog server object 228 service catalog requests from the 40 A number of program modules may be stored on the hard 

client table object 232 for configuration information on its disk, magnetic disk 316, optical disk 319, ROM 308 or 

remote computer. "Remote" does not necessarily imply that RAM 310, including an operating system 326, one or more 

a remote computer geographically distant from a local application programs 328, other program modules 330, and 

computer. Instead, remote merely indicates a cross- program data 332. A user may enter commands and infor- 

computer boundary, which may be bridged by a data bus, a 45 mation into the computer system 300 through input devices 

network connection, or other connection means. such as a keyboard 334 and mouse 336 or other pointing 

To access available catalog data in the illustrated exem- device. Examples of other input devices may include a 

plary embodiment, the administration tool 224 optionally microphone, joystick, game pad, satellite dish, and scanner, 

causes a logic table object 234 to be created, which in turn These and other input devices are often connected to the 

causes client table objects 232 and 236 to be created for so processing unit 302 through a serial port interface 340 that 

accessing available catalog server objects 226, and 228. The is coupled to the system bus 306. Nevertheless, these input 

local catalog server object 226 and the remote catalog server devices also may be connected by other interfaces, such as 

object 228 marshal the configuration information stored a parallel port, game port, or a universal serial bus (USB), 

within their corresponding computers by causing creation of A monitor 342 or other type of display device is also 

underlying table systems and transferring the data back to 55 connected to the system bus 306 via an interface, such as a 

the client table objects 232 and 236 for presentation as table video adapter 344. In addition to the monitor 342 , computer 

data to the logic table object 234, which logically merges the systems typically include other peripheral output devices 

configuration information and presents the configuration (not shown), such as speakers and printers, 

information to the administration tool 224 in table format. In The computer system 300 may operate in a networked 

the illustrated embodiment, multiple domain-specific logic go environment using logical connections to one or more 

table objects (such as logic table object 234) can reside remote computers, such as a remote computer 346. The 

between the client table objects 232 and 236, and the remote computer 346 may be a computer system, a server, 

administration tool 224. Alternatively, the administration a router, a network PC, a peer device or other common 

tool 224 may cause only a single client table object (with or network node, and typically includes many or all of the 

without overlaying logic table objects) to be created to 65 elements described above relative to the computer system 

access a single catalog server object 00 a local or remote 300. The network connections include a local area network 

computer. (LAN) 348 and a wide area network (WAN) 350. Such 
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networking environments are commonplace in offices, table interface provided to caller 416, the logic table object 
enterprise-wide computer networks, intranets, and the Inter- 418 can present to the caller a logic level table of configu- 
net. ration information, including without limitation (1) a remap- 
When used in a LAN networking environment, the com- ptog (i- c > *** alternate table configuration) of the data 
puter system 300 is connected to the local network 348 5 provided by data table object 420; (2) supplemental func- 
through a network interface or adapter 352. When used in a tionality (e.g., validation of data); and (3) synthesized data 
WAN networking environment, the computer system 300 ( c *g*. data not resident in datastore 422, but instead, data 
typically includes a modem 354 or other means for estab- derived or calculated from data in datastore 422 or another 
lishing communications over the wide area network 350, source). The logic table object 418 can also trigger external 
such as the Internet. The modem 354, which may be internal ™ operations. These features of a logic table object are 
or external, is connected to the system bus 306 via the serial described in greater detail in the previously incorporated 
port interface 340. In a networked environment, program U.S. patent application Ser. No. 09/360,440, entitled "A 
modules depicted relative to the computer system 300, or LOGIC TABLE ABSTRACTION LAYER FOR ACCESS- 
portions thereof, may be stored in the remote memory INC3 CONFIGURATION INFORMATION." 
storage device. It will be appreciated that the network 15 With regard to a table system 404, two levels of logic 
connections shown are exemplary, and other means of table objects (i.e., logic table objects 426 and 428) are 
establishing a communications link between the computers positioned between a caller 424 and a data table object 430, 
may be used. which is bound to a datastore 432. Preferably, functionality 
In an embodiment of the present invention, the computer k modularized using multiple logic table objects. For 
system 300 stores the configuration data and implementation 20 example, the logic table object 426 may be responsible for 
code providing the catalog infrastructure and disclosed and enforcing security constraints on accesses to configuration 
claimed herein in accordance with the present invention. The dala » whereas the logic table object 428 may validate data 
catalog infrastructure has without limitation one or more before writing configuration data to the datastore 432. Other 
datastores, catalog servers, runtime catalogs, server functional combinations are possible at the discretion of the 
applications, administration tools, dispensers, and wiring 25 developer. In an embodiment of the present invention, the 
databases. Specifically, one or more dispensers, preferably combinations of logic table and data table objects required 
including a table dispenser and an table object dispenser, 10 satisfy a requested database ID and table ID are specified 
provide a table object to a caller providing location and type to a wiring database accessed by the table dispenser, as 
independent access to configuration information stored in discussed more completely below. 

one or more datastores. 30 With regard to a table system 406, a caller 434 has access 
The embodiments of the invention described herein may to configuration data through a logic table object 436 
be implemented as logical operations in one or more com- without an underlying data table object or datastore. The 
puter systems. The logical operations of the present inven- togic table object 436 may provide table-based synthesized 
tion are implemented (1) as a sequence of processor- 35 data t0 me caller or otherwise provide or trigger function- 
implemented steps executing in one or more computer outside the scope of the catalog's tables. For example, 
systems and (2) as interconnected machine modules within the ^°& c table object 436 may intercept calls to an unsup- 
one or more computer systems. The implementation is a ported datastore and return errors to the caller 434. 
matter of choice, dependent on the performance require- Alternatively, the logic table object 436 may translate or 
ments of the computer system implementing the invention. remap table data originally provided by the caller 434 or an 
Accordingly, the logical operations making up the embodi- external source, rather than by a datastore. 
ments of the invention described herein are referred to With regard to a table system 408, a caller 438 gains 
variously as operations, steps, or modules. access to configuration data originally stored in or derived 
FIG. 4 depicts various examples of table systems in from datastores 450, 452, or 454. A logic table object 440 
embodiments of the present invention. Logic table and data 4S logically merges or consolidates data from a logic table 
table objects are described in the description of FIG. 2 and object 442, data table object 444, which is bound to datastore 
the incorporated references. With regard to a table system * 52 > ^ data table object 446, which is bound to datastore 
400, a caller 410 (as well as other callers in FIG. 4) may be 454 The logic table object 442 overlays a data table object 
a catalog server, a runtime catalog, or another object requir- 448f which is bound to datastore 450. In this configuration, 
ing abstracted access to a datastore. To initiate access to 50 mc *°gic table object 440 logically merges data from the 
requested information, the caller 410 provides input underlying catalog tables and presents the configuration data 
parameters, such as a database ID, a table ID, query as a logic level table to the caller 438. The data table objects 
parameters, and a level of service parameter, relating to the 444 and 446, respectively each translate the requested 
configuration information it is requesting. A table dispenser information as needed, which is discussed more completely 
(see the table dispenser 502, for example, in FIG. 5A) 55 Maw in combination with FIG. 6. 
returns to the caller 410 a pointer to a table object, in this Using combinations of information from various datas- 
case a single data table object 412 bound to a datastore 414. tores illustrates the concept of location independence. One 
Through a table interface accessible via the pointer to the call by the caller with a single table ID and a single database 
data table object 412, the caller 410 can access tabularized ID and a query gains access to configuration from many 
configuration data (i.e., a data level table) originating from 50 different locations. Indeed, the caller request does not 
the datastore 414. specify any location information, merely the configuration 
With regard to a table system 402, the table dispenser information requested. Moreover, the table system 408 illus- 
provides a caller 416 with an interface of a logic table object trates the concept of type independence in that the data from 
418, which overlays a data table object 420. The data table each of the datastores 450, 452 and 454 may all be of 
object 420 is bound to a datastore 422 and provides access 65 different type and format. 

to a data level table of configuration data originating from FIG. 5 depicts a block diagram of a table dispenser system 

the datastore 422 to the logic table object 418. Through a for dispensing a catalog table system (such as systems 400, 
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402, 404, 406 and 408 in FIG. 4) in an embodiment of the instructions may be a compilation of database specific or 

present invention. More details of the table implementation table specific wiring information, including the class IDs 

dispenser system shown in FIG. 5 and briefly discussed and related locators for one or more table object dispensers 

below are described in U.S. patent application Ser. No. (i.e., specific data table dispensers or logic table dispensers) 

09/360,445, entitled "OBTAINING TABLE IMPLEMENT- 5 corresponding to the provided database ID and table ID. 

TXTIONS USING TABLE DISPENSERS/' assigned to the After querying the wiring database 514, the table dis- 

assignee of the present application, filed concurrently here- penser 502 creates one or more table object dispensers (such 

with and incorporated herein by this reference. ^ table object dispenser 504, 506 and 508) specified in the 

Caller 500, which could include a catalog server or a wiring information, passing forward the identity, query, and 

runtime catalog, specifies the table data it requires by 10 level of service parameters. The table object required to 

passing input parameters to the table dispenser 502. provide a requested virtual table of configuration informa- 

Although FIG. 5 depicts a catalog-oriented caller, the table tion to the caller 500 may require a combination of data table 

dispenser 502 can be used more generally to provide and logic table objects. In the embodiment shown in FIG. 5, 

abstraction levels between a caller and one or more the table dispenser 502 reads a wiring relationship corre- 

datastores, without being limited to catalogs or configuration 15 sponding to the provided identity parameters from the 

data. For example, a wiring data table dispenser 515 is used wiring database 514 through the data table object 517. The 

to provide a data table object 517 for accessing data in the wiring relationship indicates both a logic table object dis- 

wiring database 514. penser 506 and the data table object dispenser 504 to satisfy 

The caller 500 passes input parameters to the table the table request from the caller 500. Accordingly, the table 

dispenser 502. In an embodiment of the present invention, 20 dispenser 502 calls the data table object dispenser 504 to 

the input parameters include identity, query, and level of create the data table object 512, binding it to the datastore 

service parameters. The identity parameter preferably 505. The table dispenser 502 then calls the logic table object 

includes a database ID and a table ID to specify the database dispenser 506 to dispense the logic table object 513, passing 

and table from which the caller 500 is requesting configu- a pointer to the data table object 512 in the calling param- 

ratioo data. 25 eters (i- e -> binding the logic table object 513 to the data table 

The query may include a query format parameter, a query ob J ect 512 > For P™P<«« discussion, the data table 

meta parameter, and a query data parameter, all of which ob J ect 512 fa referred t0 a lower-level or sub-table object 

may be NULL pointers. The query format parameter indi- of io & c ^ ob i ect 513 

cates the specific format of the query and governs the nature The logic table object dispenser 506 is programmed to 

of input data passed in the query meta and query data reuse other virtual tables to satisfy requests from callers, 

parameters. Rather than providing the entire underlying table object 

The query itself may be formatted in various ways. A first its f^ me ^ ob J ccl dispenser 506 can rely on other table 

possible query form includes a Unicode query string and a ob J ect dispensers (such as dispenser 508) to provide portions 

unique identifier of its format, such as supported in the SQL 35 of me ^ or io & c for me re q ueste d ta *>l e - That is, the table 

(Structured Query Language). A second possible query form ob J ect dispenser 506 is programmed to call the table dis- 

includes a simple "and/or" query format that supports a penser 508 with the identity (database IDs and table IDs), 

"Boolean search"-type query. In alternative embodiments, queries, and levels of service for a sub-table. The table 

other query forms may be used. dispenser 502 then re-queries the wiring database 514 with 

The level of service includes a table of flags identifying 40 *** U ™ ° f lD& ^ IDS * ° bUil1 *** 

attributes of the requested table. One level of service relates «jH«0P^ information for each sub-table object 

to read only, which reduces overhead and increases perfor- dispenser which the table dispenser 502 uses to call the 

mance since no write cache is allocated. Other levels of ^sponding data table object dispenser 508. The data 

service in a preferred embodiment that may be requested table object dispenser 508 dispenses a data table object 530, 

include "non-marshalable" which presents information that 4 S WhlCh 15 boUnd t0 datastorc 532 ' 

cannot be marshaled across processes and systems; "single Furthermore, this recursion can continue until the desired 

cursor" or "multi-cursor" which relates to the number of lo & c table ob J ecl 513 ^ dispensed. As each sub-table object 

cursors available when navigating the cached table of con- * instantiated, a pointer to the sub-table is passed up to the 

figuration information wherein each cursor indicates the Dext overlaying table object, until the multiple table objects 

table cell of data to be read or written in the resulting table 50 and/or multi P le levels of tablc objects are combined to 

of configuration information; "empty write cache" which present a requested table interface 518 from the resulting 

provides an empty write cache and no read cache when no 1°& C ^hle object 513. Alternatively, a resulting table object 

reading is expected; "incoming" which guarantees that the mav be m one of man Y assorted table system combinations, 

first client call to the table implementation will consume a including those illustrated in FIGS. 2 and 4. 

marshallable table; and "no logic" which obtains a data table 55 In the illustrated embodiment, the logic table object 513 

directly, omitting any intervening logic tables. and two sub-table objects (512 and 530) are dispensed to 

Upon receiving the identity of the requested table, the provide the caller 500 with the requested virtual table of 

table dispenser 502 queries a wiring database 514 for configuration data through the table interface 518. The 

general wiring instructions. The wiring database 514 is configuration data provided through the table interface 518 

accessed via a data table 517 that provides a defined inter- 60 & sourced from datastores 505 and 532 in FIG. 5. 

face 516 to the wiring information stored in the wiring In order to access configuration data from any of the 

database 514. The data table object 517 is dispensed to the datastores shown in FIGS. 2 and 4, a data table, such as data 

table dispenser 502 by a wiring data table dispenser 515. table object 600 shown in FIG. 6, is created and used as an 

Based on the database ID and the table ID provided by the interface to the configuration information in the datastore. 

caller, the table dispenser 502 retrieves a first level of wiring 65 The data table object 600 interacts with a datastore 602, both 

instructions from the wiring database 514, and potentially reading information out of the datastore 602 and writing 

other ancillary wiring databases (not shown). The wiring information to the datastore 602. The data table object 600 



03/31/2004, EAST Version: 1.4.1 



US 6,421,682 Bl 

13 14 

has a memory cache 604 and datastore interaction code 606 is populated with a specific configuration information table 

that performs the interaction between the da Us tore 602 and as a result of a query by a caller 612. Code 606 executes the 

the cache 604. Preferably, the data table object 600 is the query request and stores the returned information in tabular 

only interface mechanism used by the COM+ catalog (FIGS. form in the read cache 608. The data table object 600 uses 

2 and 4) to access the configuration information in the 5 the write cache 610 to store proposed modifications or 

datastore 602 such that the data table object 600 prevents additions to the datastore configuration information. Such 

caller applications from directly accessing the information in information is stored until the caller requests that the code 

the datastore 602, i.e., encapsulates the information. Instead, 606 update the datastore. At that time the code 606 uses the 

the caller operates on the cached information copied into write cache information to execute the update command, 

cache 604 from the datastore 602. Preferably the information 10 m alternative embodiments, the cache 604 comprises only 

is copied into the cache 604 creating a data level table 614 a rea d cache or a write cache. Such other embodiments are 

of configuration information that has a general row and typically beneficial in particular circumstances when only 

column table format. reading or writing is desired since those embodiments 

The datastore interaction module or code 606 receives provide better performance for quick reads or writes by 

commands from the caller and executes the commands on 15 providing a smaller working set for the caller. Preferably, the 

the datastore 602. The commands are preferably generic caller can choose a level of service that provides either the 

stemming from a predetermined set of recognized combined read and write cache 604 as shown in FIG. 6 or 

commands, i.e., a "standardized interface," and the com- just a read cache 608 or just a write cache 610. Therefore, 

mands do not depend on the type of datastore 602 or the type as little cache as necessary is allotted the data table object 

of actual commands used to access information in the 20 600 during creation which frees additional memory in the 

datastore. Instead, the datastore interaction code 606 trans- computer system to be used by other processes, 

lates the particular commands into proper format and/or Although the cache 604 and the code 606 are elements of 

sequence of specific actions necessary to access information the data table object 600, the cache and code are relatively 

in the particular datastore 602. For example, the datastore distmct from cach othcL ^ codc m performs 

may be the registry and the datastore interaction code 606 25 opcrat j ons the cachc 604 m csscnce> omcr data tables 

for accessing information in the registry may be different ( not shown) could utilize the same physical cache memory 

from the datastore interaction code (not shown) for a dif- go^ ^ i ong ^ ft has not been allocated to data table object 

ferent data table that accesses an SQL database. However, 600 or some other process 

the commands sent by the caller are standardized such that ^ ^ tab , e object 600 be m instantiated C0M 

toe caller merely makes a type-independent request not 30 ^ ^ ^ management system 

knowing what type of datastore is being used and the . ~ • t?t^c i a a a u . . / . t , , ' . 

j * , • „ *■ j £.t\£ x. « , ™ shown in FIGS. 2 and 4. As an object, the data table object 

datastore interaction code 606 handles the translation. The CAn „ ■ , r #l . * . , A „ » . , t ... 

j * i_i t. r * 600 exposes interfaces that enable the caller to interact with 

standardized command set enables the creation of new and tUa Antn t . . , • . . , . « ... 

j.ir * j - . i_ , . , . - - the data table object 600 by supplying the caller with 

different datastores by merely implementing the datastore . _ „ . t , . . r. T . • .u i. .u • * c .u * 

, r pointers to the interfaces. It is through these interfaces that 

interaction code related to the datastore format. 35 f. ^ A . • A „ * . \r * a c l j * 

the standardized methods are implemented for each data 

The datastore interaction code 606 interacts with the table. The data level table 614 is accessed through these 

datastore 602 to populate the cache and update the datastore. methods enabling the user to read and write rows and 

That is, the code 606 receives commands from the caller columns of table 614 

requesting that the cache be populated with a specific ^ ^ ^ ^ ^ ^ ^ ^ m fa 

portion of data from the datastore 602 based on a supplied eithcr me ^ ^ ^ QI ^ 

query. Code 606 generates and conducts an interaction . • , . ° . m/ ; « n . f4 . « T n 

j * *u a * * i *• ^ i . object, as shown m FIG. 2. Each of these potential callers 

command to the datastore implementing the populate _ , . 4 . , nA w ... \ - nm i 

, . . tI _ * j c mav De an instantiated COM object as part of the COM+ 

request to populate the cache with the requested informa- « * * „ i 4 . <■ 4 . 1t • 

4 ™ 4 . r , 4 4 , , . 4 , 7 4 . . catalog management system and therefore the caller 612 is 

uon. mat is tne data table code ow> translates the query into a ..^^ callcr » since thc is trusted, it eets a pointer 

the proper forma and/or necessary sequence of specific direct , mfc) ^ ^ ^ m If ^ ^ 

actions and requests the information based on the query. The J i «u • *u • c *• *i. _** 

« 4 j a ii a c ■ l~ s . trusted, the caller copies the information to another portion 

query is related to the type of information, as opposed to r . , , . . . . , .. r . 

n , tL . . * . j a*c .j. • , rr oi memory in order to maintain the integrity of the cache 

requests that simply identify specific data. memory 

a d T t T .^ m ^ dS TSf • ^ ^ 50 AsaCOM object, the data table object 600 shown in FIG. 

data table object 600 are translated by the code 606 into the fi has ia ^J ^ m ^ ^ 

specific format and/or sequence of specific actions required vWes valious me(hods to ^ e ^ 6U ^ ^ S£ , 

to update or modify the datastore 602. Preferably, the code of interfaces m ^ ^ ^ ^ ^ ^ ^ 

606 is the only executable code of the catalog schema shown daU , evel ^ o[ ^SHirton information presented to the 

in FIG 2 that B designed to modify the configuration JS ^ m me cache 604 or by omer processes to co^i ^ 

jnformation contents of the datastore 602. Such encapsula- daU teble ob - 6m ^ f(a Je ^ ^ 

ton decreases the probability that others can modify or d lQ ^ ^ ^ ^ ^ fa ^ toble ^ to 

tweak the operalional parameters of the system and thereby ^ daU ^ object 60Q fi22 ex ^^ read 

jeopardize the integrity of the system. methods and allows the caller to access and manipulate the 

Additionally, the code 606 may interact with the datastore « ax^i within the read cache 608. Interface 624 exposes the 

based on control-type commands from the caller. Such write methods. Additionally, the interface 624 inherits from 

control-type commands may include initialization of the me read interface 622 so that the caller can perform read and 

datastore 602 or merely the transfer of data to the datastore write methods using interface 624. Additionally, the data 

unrelated to the requested configuration information. table object 600 has a control interface 626 which exposes 

Allocation of the cache 604 occurs during the creation of 65 control-type methods not necessarily required to implement 

the data table 602. The cache 604 has a read cache 608 and the data table object 600 but provide added functionality to 

a write cache 610. The read cache 608 is not modifiable and the data table object 600. 
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The primary methods exposed by the data table object 600 table object 700 to perform supplemental functionality, 

generally include at least one populate method, at least one synthesize data, trigger external operations, re -map and/or 

update method, and read/write/navigate methods. Additional combine data into logic level table 706 from data level tables 

methods are also preferably exposed to enhance the func- 705 of the data table objects 704, and from other logical 

tionality of the data table object 600. The populate method s processing as programmed in the logic table object 700. 

relates to populating the read cache with data from the m ^ embodiment of the present invention, a logic table 

datastore 602 based on a supplied query. The update method 0D j ect 700 provides an abstraction layer between a caller, 

updates the datastore using information stored in the write which is presented with a logic level table 706, and one or 

cache 610. The read/navigate methods allow for row navi- more data table objects 704, which are bound to respective 

gation and enable the caller to view different rows in the 10 datastores 710. The logic table object 700 includes an 

configuration table or to view columns of information. intercepUon/delegation module 708, which maps the logic 

Additionally, the data table object 600 provides write raeth- i eve l table 706 to cursor methods and/or data in the logic 

ods to place potential changes in the write cache and table object 700. Tne interception^delegation module 708 of 

control-type methods that are exploitable by the caller 612. the illustrated embodiment may also delegate calk to the 

Since most of the operations are performed on the infor- 15 table interface of one or more of the data tables 704. By 

mation that is in cache the data in the datastore is generally delegating, the logic table object 700 effectively passes the 

encapsulated and protected from these operations. Indeed caller through to one or more underlying data table objects, 

there arc only three methods exposed that cause the code 606 By intercepting, however, the logic table 700 can provide 

of the data table object 600 to actually interact with the additional logic (e.g. supplemental functions, synthesized 

datastore 602. The methods include the read-only activity of 20 data, and mapping/consolidation) responsive to the call, 

populating the cache, the initialization method and the Depending on the specific configuration of the logic table 

update store method. ob j ect 70 0, the additional logic provided by an interception 

Data table 600 presents configuration information in data event may include consolidation of configuration informa- 
level table 614 to the caller through these methods. In the tion from multiple underlying data table objects and/or logic 
case where the caller is a logic table, such as logic table 25 table objects. Logic table objects may additionally or alter- 
object 221 in FIG. 2, the caller uses the data level table 614 natively supplement underlying table object functionality by 
to either create a logic level table for presentation to its caller intercepting cursor method calls from a client and adding to 
or uses the information to activate other services or events. or overriding the underlying table object functionality. Alter- 
In the case where the caller is a catalog server, such as nately or additionally, the logic table object 700 can syn- 
catalog server 226, then the data level table 614 may be 30 thesize data that is not available from the underlying datas- 
marshaled to a client table object, such as client table object tores or table objects and present the synthesized data as part 
232 or 236 shown in FIG. 2, located on the same computer. of the logic level table 706 presented to the caller. This 
Or, in the case where the caller is a catalog server, such as additional logic is provided by one or more logic component 
catalog server 230, then the data level table 614 may be modules 712. 

marshalled to a client table, such as client tables 236, located 35 The interception/delegation module 708 may also provide 

on a remote client computer. functions that may not necessarily be "intercepted" in that 

In order to present configuration information from at least the module 708 may provide functions called by the user 

one datastore, a logic table object 700 may be used to request directly. The caller may request the function or service, such 

information. Moreover, if more than one datastore of infor- ^ as dealing with security or another service, where the request 

mation is accessed, a logic table object 700 is used to request is implemented from the logic table object 700, as requested 

the information from the various datastores and to merge the by the caller. 

configuration information for the caller as shown in FIG. 7. A log ; c table implementation 800 in an embodiment of the 

The logic table object 700 presents a table interface 702 to present invention comprises a cache 802, an interception- 

a caller 703. The table interface 702 is compatible with the 4$ delegation module 804 and logic component modules 606 as 

interface presented by the data table objects 704 and may be s hown in FIG. 8. The logic component modules 806 have 

identical to the data table interfaces 714. The table interface onc or more synthesizing modules 808, one or more supple- 

702 includes methods for navigating rows of a logic level mental functionality modules 8 10, or one or more mapping 

table 706, getting configuration information values in tabu- modules 812 and a mapping lookup table 814. It should be 

lar form from a logic level table 706, writing to the logic 5Q understood that many combinations of the cache 802, the 

level table 706, as well lower level operations such as synthesizing module 808, the supplemental functionality 

updating the configuration information stored in a datastore, module 810, and the mapping module 812 are possible 

populating a data table object cache from a datastore, and within the scope of the present invention. Tnat is, depending 

other advanced operations. on me requirements of the logic table object, a logic table 

In order to implement logic level table navigation and 55 dispenser may include the cache and all of the modules, one 

operations, the logic table interface 702 receives all cursor or more of the modules and no cache, some intermediate 

method calls from the caller 703. More specifically, the combination of the cache and modules, or only one of the 

caller 703 requests an operation using the cursor method modules or cache. 

relating to the logic level table 706 of the logic table object Preferably, the mapping lookup table 814 is used in 

700. The caller requests the selected cursor method, passing & combination with mapping module 812. However, alternate 

appropriate parameters, to perform a particular function mapping methods may be used in another embodiment of 

provided by the cursor method. me present invention including, without limitation, those 

The operations that occur on the other side (i.e., the logic implemented by IF-THEN-ELSE constructs or CASE 

table sick) of the table interface 702 are transparent to the tables. In a preferred embodiment, a memory buffer having 

caller 703. As such, the cursor method initiated by the caller 65 data structure elements corresponding to row and column 

in the logic table object 700 can be directly delegated to an elements (e.g. coordinates) of the logic level table view 816 

appropriate data table object 704 or intercepted by the logic are recorded in a buffer as a mapping lookup table 814. The 
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data structures in the mapping lookup table 814 preferably 
include mapping instructions, such as an identifier of the 
data table object corresponding to the row and column 
combination of the logic level table 816, the corresponding 
row and column combination of the underlying data table 5 
object 818 to which the coordinate corresponds, and/or a 
pointer to additional logic. 

Upon receiving a cursor method call relating to a coor- 
dinate in logic table 816, the interception/delegation module 
804 calls a mapping module 812 to determine the mapping 1Q 
to a corresponding coordinate in an underlying data table 
818. The mapping module 812 locates the data structure 
corresponding to the coordinate of the virtual table 816 and 
returns to the interception/delegation module 804 an appro- 
priate data table 818, row and column, and additional data 
corresponding to the coordinate in the underlying table. It 15 
should be understood that more than one data table object 
and coordinate combination may be returned by the mapping 
module if the cursor method applies to multiple data table 
objects. Moreover, it should be understood that more than 
one logic table object may be incorporated between logic 20 
table object 800 and data table objects 818. The interception/ 
delegation module 804 calls a cursor method in each of the 
corresponding data table object 818 once the underlying 
table structure is defined. 

With regard to supplemental functionality module 810, 25 
the interception/delegation module 804 intercepts a call 
from the caller and calls supplemental functionality module 
810 to provide additional functionality. The supplemental 
functionality can consist of multiple stages, that is, the 
supplemental functionality module 810 can pre-process or 30 
post-process a delegation to one or more underlying data 
table objects 818. Alternatively, the supplemental function- 
ality module 810 can completely replace a cursor method of 
an underlying data table 818, foregoing delegation and 
returning to the caller through the interception/delegation 35 
module 804 (without calling a cursor method in an under- 
lying data table object 818). Examples of supplemental 
functionality include without limitation enforcing complex 
relationships among column values in a row when a caller 
attempts to change the values in a column, filtering server- 40 
side row or column reads depending on the security level of 
a caller, enforcing and managing complex relationships 
among different tables as those tables change, and triggering 
external functionality that lies outside the scope of the 
catalog tables, responsive to predetermined table changes, 45 
Triggering external functionality may also involve the trig- 
gering of events that relate to the changes made to the 
datastore, including loosely coupled events and other func- 
tion calls. 

Implementing the data tables to provide the functionality 50 
as described above enables the upper levels of abstraction 
and program code, including the catalog server, logic tables, 
runtime catalog, etc. to separate themselves from the pri- 
mary aspects related to actually storing and retrieving data. 
The data tables provide an interface that is relatively inde- 55 
pendent of the type or format related to the particular 
datastore. Additionally, this particular method of interfacing 
with datastores makes it fairly simple to implement a new 
and different datastore. Additionally, the combination of the 
logic tables with the data tables provides the necessary 60 
location independence since desired configuration informa- 
tion stored in many different locations may be presented 
through a single logic table. Furthermore, the combination 
allows necessary services to be provided despite location or 
type of data stored in the various datastores. 65 

The general operations involved with creating and using 
the combination of logic table objects and data table objects, 
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such as table systems 400, 402, 404, 406 and 408 shown in 
FIG. 4 are shown at 900 in FIG. 9. Initially, the operation 
flow begins with request operation 902 wherein the caller 
requests a table of configuration informatioa In a preferred 
embodiment the request does not include particular infor- 
mation as to the location of any datastore or the type of any 
datastore. Instead the request includes a database ID, a table 
ID, and possibly a query related to the requested informa- 
tion. The caller sends this request to the catalog management 
system, and more particularly to the table dispenser. 

Receive operation 904 in the table dispenser receives the 
request from the caller. The table dispenser may be either on 
the same computer system as the caller process or the table 
dispenser may be on another, remotely connected computer 
system. As part of operation 904, the table dispenser pref- 
erably analyzes the request and determines the location of 
the information. In an embodiment of the present invention, 
the information related to the various datastores and types of 
configuration information is stored in a "wiring database." 
The table dispenser uses the wiring database to analyze a 
request and determine the type of table object dispensers to 
create. Once the table dispenser determines the location of 
the information, create operation 906 creates a table object 
dispenser. The table object dispenser is an object that 
performs the function of creating either a data table object or 
a logic table object. 

Following creation of the table object dispenser, decision 
operation 908 determines whether other table dispensers 
must be implemented or created. Preferably, each instance of 
a table dispenser contains the necessary information to 
determine whether other dispensers must be formed based 
on the parameters used during its creation. 

If other table object dispensers are to be created then flow 
branches YES and a request for another table object is sent 
to the table dispenser. Process steps 904, 906 and 908 repeat 
until no other table object dispensers are to be created. 

Following creation of the table object dispensers, create 
operation 910 create any and all data table objects necessary 
for the table system. Each table object dispenser designed to 
create a data table object executes its function of creating the 
data table objects at operation 910. 

Once all the data table objects have been created, create 
operation 912 creates the logic table objects. In similar 
manner as the creation of the data table objects, create 
operation 912 uses the table dispensers designed to create 
logic table objects to perform the function of creating the 
logic table objects. 

Preferably, the data table objects have read caches asso- 
ciated with them. As discussed above, some may only have 
a write cache, but most often a read cache is implemented 
along with the data table object. Accordingly, the read cache 
is preferably populated with configuration information prior 
to returning a pointer to the caller process. Therefore, 
populate operation 914 populates the cache following cre- 
ation of the logic table objects. In alternative embodiments, 
the cache is populated before or simultaneously with the 
creation of the logic tables. Also, other embodiments do not 
populate the cache until requested to do so by the caller. 

Following population of the cache, provide operation 916 
provides the logic table objects) with the pointer or pointers 
to the interfaces associated with the data table object(s) 
interfaces. In alternative embodiments, the creation of the 
logic table objects, operation 912, automatically returned 
pointers related to the data table objects directly to the logic 
table objects. In either case, providing the logic table objects 
with the proper pointers enables both interception and 
delegation of calls to the data table objects. 
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The process concludes with reply operation 918 which 
replies to the caller, providing the caller with a pointer to the 
logic table interface, and a cursor pointer to cached 
information, Le., the logic level table. 

The above specification, examples and data provide a 5 
complete description of the manufacture and use of the 
composition of the invention. Since many embodiments of 
the invention can be made without departing from the spirit 
and scope of the invention, the invention resides in the 
claims hereinafter appended. 10 

What is claimed is: 

1. A computer implemented catalog management system 
having an abstraction layer for accessing system configura- 
tion information and presenting the configuration informa- 
tion to a computer process caller within a computer system, 15 
wherein the caller supplies a call having a query related to 
requested configuration information, the configuration infor- 
mation originally stored in a datastore, said abstraction layer 
comprising: 

a cache memory module accessible by the caller and 20 
adapted to store the configuration information to be 
presented to the caller; 

a data table object interface module having a datastore 
interaction code module adapted to retrieve informa- ^ 
tion from the datastore and populate the cache memory 
module with the configuration information; and 

a logic table object interface module having an 
interception/delegation module for receiving calls from 
the caller and delegating commands to the data table 30 
object interface module to produce a logic table object 
having configuration information related to the query. 

2. A system as defined in claim 1 wherein the abstraction 
layer is adapted to present configuration information to the 
caller in response to a location independent request. 35 

3. A system as defined in claim 2 wherein the abstraction 
layer is adapted to present configuration information to the 
caller from more than one datastore. 

4. A system as defined in claim 3 wherein the abstraction 
layer uses a wiring database to determine the location of the 40 
datastores to provide the configuration information. 

5. A system as defined in claim 1 wherein the abstraction 
layer is adapted to present configuration information to the 
caller in response to a type independent request. 

6. A system as defined in claim 5 wherein the abstraction 
layer is adapted to present configuration information to the 
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caller from more than one datastore wherein the information 
is stored in each datastore in a different format. 

7. A system as defined in claim 6 wherein the abstraction 
layer uses a wiring database to determine the location of the 
datastores to provide the configuration information. 

8. A system as defined in claim 1 wherein the abstraction 
layer is adapted to present configuration information to the 
caller in tabular form. 

9. A system as defined in claim 8 wherein the abstraction 
layer is adapted to present configuration information to the 
caller from more than one datastore. 

10. A system as defined in claim 9 wherein the abstraction 
layer is adapted to present configuration information to the 
caller wherein a portion of the information is synthesized 
information. 

11. A system as defined in claim 9 wherein the abstraction 
layer is adapted to provide services to the caller in response 
to a call for configuration information. 

12. A system as defined in claim 9 wherein the abstraction 
layer triggers external function calls in response to a request 
for configuration information. 

13. A system as defined in claim 1 wherein the abstraction 
layer operates in an attribute based processing module. 

14. A system as defined in claim 1 wherein the cache 
memory module is part of the data table object. 

15. A system as defined in claim 1 wherein the cache 
memory module is part of the logic table object. 

16. A system as defined in claim 1 comprising more than 
one data table object, each data table object providing 
information to the logic table object. 

17. A system as defined in claim 1 further comprising 
more than one logic table object, wherein one logic table 
object provides the caller with requested configuration infor- 
mation. 

18. A system as defined in claim 17 further comprising a 
plurality of data table objects, each data table object pro- 
viding information to one of the aforementioned logic table 
objects and wherein the logic table objects are adapted to 
provide services in response to the requested information. 

19. A system as defined in claim 1 wherein the logic table 
object intercepts predetermined calls to the data table object, 
delegates predetermined calls to the data table object, and 
performs predetermined calls to the logic table object. 

# + * + * 
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